feat(ui): Moss group context for groups and NDOs - #181

Inside Moss the Moss group already holds membership and profiles, so the Lobby, the invite codes and LobbyAgentProfile would duplicate it. Decided on 2026-11-03: one Nondominium group per Moss group, namely the tool instance's group cell, joined automatically; profiles from profilesClient; roles from myAccountabilitiesPerGroup(); no work context in v0.1.0.

• The seam. LobbyServiceResolved in lobby.service.ts is MossLobbyServiceLive when detectCurrentHost() says Moss and LobbyServiceLive otherwise. Stores, NdoService and components keep calling the same LobbyService interface.
• moss-lobby.ts (the Moss implementation, dependencies injected so it runs in a unit test against a mocked WeaveClient): one group, id moss. The tool installer (toolInstaller) creates the GroupProfile, named after the Moss group; every other member waits for it to gossip (up to about 30 s), then joins. One resolution runs at a time and a successful one is kept, because the stores and the NDO service all ask at once and concurrent create_group and join_group commits fail with source chain head has moved (the recorded run found this). Create group, join group and invite links answer Groups are managed by Moss; the Lobby DHT calls answer with nothing.
• moss/group-cell.ts: finds the provisioned group cell (Moss installs deferred roles as provisioned cells, see research: Moss spike, install the happ in weave dev mode and clone one NDO #162).
• moss/profile.ts: maps the Moss profile to LobbyUserProfile, reads the roles of the instance's group, picks the strongest (Member, Steward, Progenitor).
• moss/ndo-clone.ts and holochain.service: in Moss, NDO clones are created and enabled through the WeaveClient, since the applet client refuses clone management.
• moss.store.svelte.ts and components: the layout loads the Moss profile instead of asking for a Lobby profile; the sidebar shows the Moss nickname and role; create group, join group, invite link, profile edit and the per-group disclosure modal are hidden inside Moss. Each is wrapped in the existing component, none is a new element beside it.
• Docs: moss-integration.md (group context section), ui_architecture.md, IMPLEMENTATION_STATUS.md, CHANGELOG.md.

git checkout feat/moss-group-context
nix develop -c bun run --filter ui check
nix develop -c bash -c 'cd ui && bunx vitest run --project server'
nix develop -c bun run e2e
nix develop -c bun run tool-dev          # two Moss windows

Recorded two-agent dev-mode run (2026-11-03, repo config, nested X server, driven through the tool iframes over CDP):

1. Alice and Bob each open the tool. Both show the group Nondominium Pilot with no invite code, Alice · Progenitor and Bob · Progenitor in the sidebar (every dev agent is Progenitor), and Signed in as Alice and Signed in as Bob from the Moss profiles. No create, join or invite control is visible.
2. Alice opens the group and creates the NDO Moss Seed Library through the form. The clone is created through the WeaveClient and anchored in the group cell.
3. Bob reloads the tool and the card Moss Seed Library (Ideation, Commons, Physical) is in his NDO browser.

Updated in this PR: moss-integration.md, ui_architecture.md, IMPLEMENTATION_STATUS.md, CHANGELOG.md. lobby-architecture.md §9 was marked partly superseded in #180.

• Closes feat(moss): Moss group context for groups and NDOs #164
• Depends on: feat(moss): Moss tool scaffold #163 (feat(ui): run Nondominium as a Moss tool in weave dev mode #180), chore(deps): upgrade to Holochain 0.7.1 #130, research: Moss spike, install the happ in weave dev mode and clone one NDO #162 (research: Moss spike, install the happ in weave dev mode and clone one NDO #162 (comment))
• Follow-up: feat(moss): NDOs as Moss assets #165